The disclosures herein relate generally to automated production environments and, more particularly, to a technique for performing very high speed software downloads concurrent with system testing in such an environment.
Historically, computer manufacturers have tested computer systems in production under DOS. There are several problems with this. First, because DOS is not a multi-tasking operating system, as the complexity of the computer systems being tested increases and more tests are required, the time required to perform those tests also increases, resulting in reduced manufacturing throughput. Second, DOS does not support testing of certain types of systems, such as Symmetrical Multi-Processor (xe2x80x9cSMPxe2x80x9d) systems and RAID controllers, which must be tested under a multi-tasking operating system. Finally, DOS will not execute under 64-bit processors shipped on certain computer systems; a multi-tasking operating system will be necessary to properly test such systems.
A process has been developed to solve the above-noted problems; namely, to provide support for components that could not be tested under DOS and to reduce test times through parallel testing. This process, referred to herein as xe2x80x9cWinTestxe2x80x9d, installs from DOS onto a target system, and then boots to a multi-tasking OS, such as Windows NT Server, Enterprise Edition (xe2x80x9cNTSExe2x80x9d), available from Microsoft Corporation, Redmond, Wash., launches and runs Windows-based diagnostics, and then boots back to DOS. However, in running applications and tests under a multi-tasking environment, there are three fundamental problems, including (1) how to control the application or test, (2) how to determine pass/fail status for the application or test, and (3) how to communicate this status to the WinTest architecture.
In a DOS environment, the foregoing tasks are fairly simple. Most applications are controlled through command line parameters or configuration files; pass/fail status is typically returned through an ERRORLEVEL environment variable; and the only installation/removal involves adding/deleting files. Working under a multi-tasking environment, such as NTSE, however, is much more complicated. Each application is controlled differently, often through mouse/keyboard events, each application determines pass/fails status differently, often by opening/closing windows, changing window contents, and creating files, for example, and installing applications often requires manipulation of the registry, base files, and shared files and ActiveX Servers. Thus, there is no standard way to integrate applications/tests into the automated production environment.
An additional problem suffered in the DOS environment is that production-installed software is downloaded in the burnracks in a sequential manner. Accordingly, as the size of the software installs continues to grow, the download times also continue to increase, which reduces production speeds and increases cost-per-system. While network speed increases can help to alleviate this problem to some extent, at some point, the download becomes limited to the performance of the hard drive on the client system and download times increase linearly with download sizes. There is currently no means to reduce the impact of the software downloads once the client hard drive limit has been reached.
In the build-to-order environment, each system executes a unique set of process steps in production. In the DOS environment, this sequence is specified in a xe2x80x9cstep filexe2x80x9d and the actual sequencing is controlled by an application referred to as xe2x80x9cRunStep.xe2x80x9d RunStep, however, only provides sequential step execution. Under WinTest, each production system has a multi-tasking OS, such as NTSE, installed in the burnracks and multiple diagnostics (over 20) are run in parallel. The ability to run these diagnostics in parallel significantly reduces total test time (by over ten hours in the case of servers), which provides a large competitive advantage. However, RunStep does not provide the ability to execute steps in parallel. Further, in the DOS environment, the step execution, status display, test log viewing, and Electromechanical Repair (xe2x80x9cEMRxe2x80x9d) debug tools are deployed as separate tools. This requires extensive EMR training, adds significant overhead to the EMR process, and makes it impossible to determine the location of the system in the overall test process while it is running.
Therefore, what is needed a system that enables software downloads to be performed in parallel with system testing and that provides a sequencing engine that enables the execution of xe2x80x9cstepsxe2x80x9d in parallel under a multi-tasking OS, such as NTSE.
One embodiment, accordingly, provides a method and system for performing very high speed software downloads concurrent with system testing in an automated production environment and for test-sequencing in multi-tasking environments with consolidated automation and interactive operations. To this end, performing high-speed software downloads to and diagnostic testing of a target computer system in a manufacturing environment includes booting the target computer system to a multi-tasking operating system and launching a step sequencing engine application. The step sequencing engine application simultaneously launches a diagnostics platform and a software download manager. The diagnostics platform initiates a plurality of diagnostic tests to be performed on the target computer system and the software download manager simultaneously launches a software download tool for downloading customer software to a hard drive of a target computer system. Upon completion of the diagnostic tests and the customer software downloading, the target computer system reboots to DOS.
A technical advantage is that software downloads and diagnostics can be performed on an target system in parallel, thereby significantly reducing the time required to complete testing and software downloads and increasing production throughput.
Another technical advantage is that all of the tools necessary to debug a target system are combined into the sequencing engine, thereby significantly reducing the amount of time needed to debug a target system.
Yet another technical advantage is that logs are consolidated and given descriptive names such that a variety of logs can be accessed from a single Log View window of the WinStep application.
Yet another technical advantage is that problematic steps can be rerun from an EMR Control window of the WinStep application.